RE:CZ

Reflexiones sobre la práctica de programación con IA: Problemas de OOP y compatibilidad excesiva

Ingeniería de Software de IA

👤 Desarrolladores de IA, programadores, gerentes técnicos y entusiastas de la tecnología interesados en prácticas de programación con IA
Basado en registros del 3 de febrero de 2026, este artículo reflexiona sobre problemas en la práctica de programación con IA. El autor señala que incluso modelos SOTA como Opus 4.5 no son adecuados para escribir código de programación orientada a objetos, ya que la IA carece de una comprensión profunda del dominio empresarial y capacidad de modelado. La IA puede devolver la deuda técnica mediante procesos específicos, pero la OOP y la compatibilidad excesiva siguen siendo desafíos principales. La compatibilidad excesiva conduce a código inflado y colapso cognitivo, y la programación es esencialmente un problema de ciencia cognitiva que requiere manejar negocios únicos. El artículo enfatiza que el desarrollo cognitivo es un proceso en espiral ascendente, donde el código y los experimentos ayudan a obtener cognición y, a su vez, a escribir mejor código.
  • ✨ La IA no es adecuada para escribir código de programación orientada a objetos, carece de capacidad de modelado empresarial
  • ✨ Incluso modelos SOTA como Opus 4.5 tienen esta limitación
  • ✨ La IA puede devolver la deuda técnica mediante procesos específicos
  • ✨ La compatibilidad excesiva conduce a código inflado y colapso cognitivo
  • ✨ La programación es esencialmente un problema de ciencia cognitiva que requiere manejar negocios únicos
📅 2026-02-03 · 434 words · ~2 min read
  • Programación con IA
  • Programación orientada a objetos
  • Deuda técnica
  • Compatibilidad excesiva
  • Ciencia cognitiva
  • Opus 4.5
  • Mantenimiento de código

Aplicación de la Autonomía de la IA y la Alineación de la Perspectiva Científica en el Diseño de RFC

Ingeniería de Software de IA

👤 Ingenieros de software, investigadores en IA, gestores técnicos, y personas interesadas en la colaboración humano-máquina y el desarrollo ágil
Este artículo discute la importancia de la autonomía de la IA en la ingeniería de software, especialmente en la aplicación al diseño de RFC (Request for Comments). El autor señala que el núcleo de la autonomía de la IA está en la alineación de la perspectiva científica, es decir, la IA necesita comprender y seguir los conceptos y metodologías científicas humanas, como el principio de la navaja de Occam, para evitar un diseño excesivo y la complejización. El artículo sugiere adoptar una arquitectura generativa adversaria, donde la IA de revisión de RFC cuestione las decisiones de diseño de la IA generadora, y respalde las decisiones de diseño mediante restricciones basadas en hechos. Estos hechos deben ser verificables por terceros, lo que puede lograrse diseñando código experimental para su validación. El objetivo final es lograr una autonomía eficiente de la IA, reducir los costos de intervención humana y promover un modelo de desarrollo ágil.
  • ✨ El núcleo de la autonomía de la IA radica en la alineación de la perspectiva científica, necesitando seguir los conceptos científicos humanos
  • ✨ Aplicar el principio de la navaja de Occam para simplificar el diseño de RFC, evitando complejizaciones innecesarias
  • ✨ Adoptar una arquitectura generativa adversaria, donde la IA de revisión cuestione las decisiones de diseño de la IA generadora
  • ✨ Las decisiones de diseño deben basarse en restricciones de hechos, que deben ser verificables por terceros
  • ✨ Verificar hechos mediante código experimental, siguiendo el método científico
📅 2026-01-29 · 711 words · ~4 min read
  • Autonomía de la IA
  • Alineación de la Perspectiva Científica
  • Diseño de RFC
  • Navaja de Occam
  • Arquitectura Generativa Adversaria
  • Restricciones Basadas en Hechos
  • Colaboración Humano-Máquina
  • Desarrollo Ágil

Análisis del futuro de los programadores y tendencias de crecimiento de la demanda de software en la era de la IA

Ingeniería de Software de IA

👤 Programadores, profesionales de tecnología, personas interesadas en IA y tendencias futuras
Este artículo comienza con la rutina personal a las 4 a.m. en 2026, discutiendo el impacto de la IA en la profesión de programador. El autor considera que la teoría del desempleo de programadores es demasiado unilateral, siendo clave si la demanda crece. Propone tres puntos de crecimiento en la demanda futura de software: aumento de necesidades personalizadas, tendencias de descentralización (especialmente en sistemas de distribución de tráfico) y la programabilidad universal (incluyendo IoT, VR/AR, etc.). Finalmente, enfatiza que el futuro es una era del gusto, donde los individuos deben mejorar su gusto e influencia, y los productos volverán a una dirección de desarrollo impulsada por el gusto.
  • ✨ La teoría del desempleo de programadores bajo el impacto de la IA debe considerar el crecimiento de la demanda
  • ✨ Las necesidades personalizadas aumentarán significativamente la demanda de software
  • ✨ Las tendencias de descentralización traen nuevas formas de productos y demanda de sistemas de distribución de tráfico
  • ✨ La programabilidad universal extiende el desarrollo frontend a dispositivos físicos y nuevos campos
  • ✨ El futuro es una era del gusto, los individuos deben mejorar su gusto e influencia
📅 2026-01-28 · 1,057 words · ~5 min read
  • IA
  • Programadores
  • Tendencias futuras
  • Descentralización
  • Necesidades personalizadas
  • Programabilidad universal
  • Gusto

Análisis del rendimiento y propuestas de mejora para tareas de traducción con Agent

Ingeniería de Software de IA

👤 Desarrolladores de IA, investigadores en procesamiento del lenguaje natural, técnicos interesados en tecnologías Agent y LLM
Este artículo analiza las razones por las que Agent tiene un rendimiento inferior a LLM one-shot en tareas de traducción, incluyendo un alto uso de tokens, disminución de la calidad de traducción y errores de formato en YAML Frontmatter. El autor considera que el diseño de Agent es más adecuado para tareas de razonamiento y toma de decisiones en múltiples pasos, y su estrategia de gestión de contexto impide aprovechar completamente la información para la traducción. También se menciona que Agent puede entrar en bucles infinitos al traducir idiomas minoritarios. Para abordar estos problemas, el autor propone dos soluciones: utilizar el framework Agents/Sub-Agents para descomponer la tarea de traducción, o ensamblar habilidades (Skill) con API de LLM one-shot de bajo nivel. El autor prefiere la primera opción y discute el nivel de soporte de OpenCode para llamadas complejas de Agent. Finalmente, el artículo revisa los registros de actualización de las versiones CZON 0.5.0 a 0.5.2, incluyendo la integración de OpenCode, correcciones de problemas de red y la reversión de la funcionalidad de traducción con Agent.
  • ✨ Agent tiene un rendimiento inferior a LLM one-shot en tareas de traducción
  • ✨ Agent utiliza 10 veces más tokens que LLM
  • ✨ La calidad de traducción disminuye y aparecen errores de formato en YAML Frontmatter
  • ✨ El diseño de Agent es más adecuado para tareas de razonamiento y decisión en múltiples pasos
  • ✨ La estrategia de gestión de contexto impide aprovechar completamente la información
📅 2026-01-23 · 516 words · ~3 min read
  • Agent
  • Tarea de traducción
  • LLM
  • OpenCode
  • CZON
  • Análisis de rendimiento
  • Propuesta de mejora

Reflexiones sobre la experiencia de desarrollo con IA: Limitaciones y direcciones de mejora de los LLM desde la construcción de CZONE

Ingeniería de Software de IA

👤 Desarrolladores de IA, investigadores de LLM, entusiastas de la tecnología y personas interesadas en la aplicación de la IA en el desarrollo de software.
Este artículo registra la experiencia del autor el 19 de enero de 2026 al construir desde cero la versión en línea de CZON (CZONE) usando OpenCode y MiniMax M2.1. La IA fue rápida en la selección de tecnologías, configuración de scaffolding y diseño de funciones, pero mostró una comprensión insuficiente de los detalles al manejar problemas de permisos con la API REST de GitHub, especialmente al no reconocer los requisitos especiales de permisos para el directorio .workflows. El autor señala que los LLM tienen problemas de atención dispersa y capacidad de razonamiento débil en modo de depuración, sugiriendo la introducción de un "modo laboratorio" para realizar experimentos de control. Además, OpenCode carece de capacidad de control del navegador, lo que hace que la depuración dependa de la revisión manual de registros; el autor recomienda integrar marcos de pruebas de extremo a extremo como Cypress o Playwright. Además, el ritmo de desarrollo con IA es demasiado rápido, carece de capas de arquitectura y garantía de calidad, y el autor lo compara con "agua que se desborda", enfatizando la necesidad de conceptos, abstracciones e implementaciones correctas. El artículo concluye con una analogía de un fontanero reparando una fuga, insinuando que el desarrollo con IA requiere soluciones sistémicas a problemas fundamentales en lugar de parches temporales.
  • ✨ La IA tiene una comprensión insuficiente de los detalles en el manejo de permisos de la API de GitHub, especialmente para los permisos especiales del directorio .workflows
  • ✨ Los LLM tienen atención dispersa y capacidad de razonamiento débil en modo de depuración; se sugiere introducir un modo laboratorio para experimentos de control
  • ✨ OpenCode carece de capacidad de control del navegador, la depuración depende de lo manual; se recomienda integrar marcos de pruebas de extremo a extremo
  • ✨ El ritmo de desarrollo con IA es demasiado rápido, carece de capas de arquitectura y garantía de calidad; necesita métodos de desarrollo más sistemáticos
  • ✨ El autor compara la IA con un "cerebro en una cubeta" y "agua que se desborda", enfatizando la importancia del ciclo de pensamiento y la distribución de energía
📅 2026-01-19 · 853 words · ~4 min read
  • Desarrollo con IA
  • Limitaciones de LLM
  • OpenCode
  • Capacidad de depuración
  • API de GitHub
  • Gestión de permisos
  • Ritmo de desarrollo
  • Modo laboratorio

Reflexiones sobre el Diseño de Arquitectura de Ingeniería de Software a Nivel de Módulo con Agentes de IA

Ingeniería de Software de IA

👤 Ingenieros de software, desarrolladores de IA, profesionales técnicos interesados en programación automatizada y colaboración humano-máquina
Este artículo documenta las reflexiones del autor el 12 de enero de 2026 sobre la aplicación de Agentes de IA en ingeniería de software a nivel de módulo. El autor propone una arquitectura de colaboración humano-máquina, cuyos puntos clave incluyen: usar git worktree para gestionar repositorios de código, invocar Agentes de IA (como Claude Code) a través de CLI y gestionar sesiones, obtener notificaciones de finalización e historial de conversaciones del Agente para lograr transparencia. El autor planea implementar un script automatizado que asigne cada tarea a una sesión independiente del Agente y coordine el flujo de trabajo mediante un planificador. El artículo enfatiza las ventajas de usar Agentes en lugar de invocar directamente APIs de LLM, ya que los Agentes manejan complejidades subyacentes (como explorar repositorios de código, invocar comandos del sistema, gestión de contexto), evitando reinventar la rueda. El autor pretende implementar primero una versión simplificada para validar la idea.
  • ✨ Diseñar una arquitectura de ingeniería de software a nivel de módulo basada en colaboración humano-máquina
  • ✨ Usar git worktree para gestionar repositorios de código y scripts de configuración
  • ✨ Invocar Agentes de IA (como Claude Code) a través de CLI para iniciar sesiones
  • ✨ Obtener notificaciones de finalización e historial de conversaciones del Agente de IA para lograr transparencia
  • ✨ Implementar un script automatizado que asigne sesiones independientes a cada Agente
📅 2026-01-12 · 387 words · ~2 min read
  • Agente de IA
  • Ingeniería de software
  • Colaboración humano-máquina
  • Claude Code
  • Automatización
  • Modularidad
  • Transparencia
  • Planificador

Discusión sobre Observabilidad y Métodos de Ingeniería en Código Generado por LLM

Ingeniería de Software de IA

👤 Ingenieros de desarrollo de software, desarrolladores de aplicaciones de IA, gerentes técnicos y profesionales interesados en LLM y observabilidad
Este artículo documenta la discusión del autor con Hobo sobre la aplicación del código generado por LLM en entornos de producción. Los puntos clave incluyen: el código generado por LLM no puede usarse directamente en producción y debe garantizarse mediante pruebas rigurosas y observabilidad; la observabilidad requiere puntos de instrumentación intrusivos, aislamiento de recursos y sistemas de alerta, y se recomienda incrustar reglas de alerta en el código; el autor y Hobo difieren en la importancia de la inteligencia del LLM versus los métodos de ingeniería, donde el autor considera que los métodos de ingeniería (como cadenas de prompts y flujos de prueba) son más críticos en la etapa actual, mientras Hobo enfatiza el papel fundamental de la inteligencia del modelo, siendo ambos complementarios y valiosos para el equipo.
  • ✨ El código generado por LLM no puede usarse directamente en entornos de producción debido a su insuficiente confiabilidad
  • ✨ La observabilidad (como puntos de instrumentación y reglas de alerta) es crucial para garantizar la estabilidad del servicio a largo plazo
  • ✨ La observabilidad requiere implementación intrusiva y debe combinarse con aislamiento de recursos
  • ✨ Las reglas de alerta deben incrustarse en el código para mejorar la colaboración entre desarrollo y operaciones
  • ✨ Los métodos de ingeniería (como flujos de prueba) tienen mayor valor en la etapa actual de aplicaciones de LLM
📅 2026-01-11 · 1,091 words · ~5 min read
  • LLM
  • Observabilidad
  • Generación de código
  • Métodos de ingeniería
  • Inteligencia artificial
  • Entorno de producción
  • Pruebas

Reflexiones sobre la práctica de programación con IA: Evitar OOP y compatibilidad excesiva

Ingeniería de Software de IA

👤 Desarrolladores de software, entusiastas de tecnología de IA, principiantes en programación, ingenieros preocupados por la calidad y mantenibilidad del código
Este artículo documenta las experiencias fallidas del autor al usar IA para programación (Vibe Coding), descubriendo que el código orientado a objetos generado por IA es de baja calidad y estructura desordenada, lo que lleva a una explosión de deuda técnica. El autor analiza las causas, incluyendo la capacidad insuficiente de la IA para diseñar paradigmas OOP, la falta de orientación arquitectónica y la compatibilidad excesiva hacia atrás. El artículo propone recomendaciones clave: evitar la programación orientada a objetos, cambiar a programación orientada a procesos y funcional; guiar a la IA para comprender el principio de la navaja de Occam, reduciendo la hinchazón del código. Estas medidas tienen como objetivo mejorar la calidad y mantenibilidad del código generado por IA.
  • ✨ El código orientado a objetos generado por IA es de baja calidad, estructura desordenada, lo que lleva a una explosión de deuda técnica
  • ✨ La IA tiene capacidad insuficiente para diseñar paradigmas OOP, carece de modelado de dominio de negocio
  • ✨ La IA carece de orientación arquitectónica, adopta estrategias perezosas, el código está hinchado
  • ✨ La compatibilidad excesiva hacia atrás aumenta la complejidad del código y los costos de mantenimiento
  • ✨ Se recomienda evitar el uso de OOP, cambiar a programación orientada a procesos y funcional
📅 2026-01-07 · 857 words · ~4 min read
  • Programación con IA
  • Programación orientada a objetos
  • Programación funcional
  • Calidad del código
  • Deuda técnica
  • Navaja de Occam
  • Compatibilidad hacia atrás

Diseño de Arquitectura de Ingeniería de Software Colaborativa Humano-Máquina a Nivel de Módulo

Ingeniería de Software de IA

👤 Ingenieros de software, investigadores en IA, gerentes técnicos y profesionales interesados en colaboración humano-máquina y desarrollo de software automatizado.
Este artículo aborda los problemas de baja calidad, límites poco claros y lentitud de los Agentes de IA existentes en la implementación de módulos de código, proponiendo una arquitectura de ingeniería de software colaborativa humano-máquina a nivel de módulo. La arquitectura genera una Especificación de Protocolo mediante alineación rápida de intenciones, luego genera en paralelo especificaciones de implementación, pruebas y referencia, y asegura la calidad de la implementación a través de mecanismos de arbitraje multinivel. El diseño central incluye colaboración en capas, división especializada del trabajo y separación de preocupaciones, estableciendo criterios de aceptación claros (pruebas unitarias aprobadas, rendimiento no degradado) para crear un mecanismo de confianza y eliminar el deseo de control humano. El artículo también discute problemas no resueltos como mejorar la calidad de la Especificación de Protocolo y evitar ciclos de arbitraje, y anticipa la posibilidad de reemplazar la supervisión humana con IA de nivel superior.
  • ✨ Los Agentes de IA existentes tienen problemas de baja calidad, límites poco claros y lentitud en la implementación de módulos de código
  • ✨ Propone una arquitectura colaborativa humano-máquina a nivel de módulo, generando una Especificación de Protocolo mediante alineación rápida de intenciones
  • ✨ La arquitectura utiliza colaboración en capas, generando en paralelo Especificaciones de Implementación, Pruebas y Referencia
  • ✨ Asegura la calidad de la implementación mediante mecanismos de arbitraje multinivel, reduciendo la intervención humana
  • ✨ Establece criterios de aceptación claros: pruebas unitarias aprobadas y rendimiento no degradado, para crear un mecanismo de confianza
📅 2026-01-05 · 1,803 words · ~9 min read
  • Colaboración Humano-Máquina
  • Ingeniería de Software
  • LLM
  • Agente de IA
  • Diseño de Módulos
  • Mecanismo de Arbitraje
  • Desarrollo Automatizado